[#824] Answer each batchRequest of a SOAP body with its own batchResponse - #836

… on missing Content-Type

performLDAPRequest() returns null for an abandon request, but doPost()
dereferenced the result unconditionally, so a batch containing
<abandonRequest/> ended in a NullPointerException; as the connection was
closed after the loop instead of in a finally, one LDAP connection was
leaked per request.

messageFactory was only assigned when a SOAP 1.1 or SOAP 1.2 Content-Type
header was present, and was then dereferenced both when parsing the request
and when sending the response: a POST without Content-Type ended in a
NullPointerException, and, when an error response had already been queued,
in an empty HTTP 200 instead of that error. A missing or unsupported
Content-Type is now answered with a malformedRequest batch response.

Also log the failure instead of printing the stack trace when the response
cannot be sent, and add regression tests for both defects.

Report the failure to send the response to the container log: the
java.util.logging record was dropped, as connectToHost() resets the
LogManager and turns the root logger off on every non-verbose
connection. This needs super.init(config), without which
getServletContext() throws.

Drop the authzid of the previous batch request before setting the new
one: the connection options are shared by the whole SOAP body and
addSASLProperty() appends to the values of a key, so a second
authRequest made SASL PLAIN reject a multi-valued authzid. Now that the
connection is never reused, make it a loop local and remove the dead
null check that guarded the reuse.

Build the malformed Content-Type response with
createXMLParsingErrorResponse(), like the other two malformed paths, so
that the requestID is recovered; and keep reading the headers after a
malformed Authorization one, so that the reply keeps the SOAP version of
the request.

Cover the SOAP 1.2 path, the per-batch-request connection and the
authzid, let the fake LDAP endpoint serve several connections and fail
the test on a server-side error, and pin the createSocket() regression
of OpenIdentityPlatform#279 with a test in the module that owns it.

…uest of a SOAP body

The connection options are built once per doPost() and shared by all the batch
requests of the SOAP body, but the authzid was dropped only when the next batch
request carried an authRequest of its own. A body whose first batch request asks
for an authorization identity and whose second does not left the first authzid in
the options, so the operations of the second one ran under an identity the request
never asked for. It is gated on ldap.authzidtypeisid=true, which the shipped
web.xml leaves at false, and still subject to the proxied-auth privileges of the
server. The clearing now happens at the top of every iteration, before the
authRequest is looked at.

DSMLServletTestCase records the authorization identity of every SASL bind at the
fake endpoint: the existing test now asserts the identities themselves instead of
the mere absence of an error, and a new one pins the mixed body, where the second
batch request must bind with no authzid at all.

The four remaining Logger.getLogger(PKG_NAME) calls are replaced by
getServletContext().log(), so the class has a single logging sink: they were dead
for the reason already documented for the response path, which moves to the class
javadoc.

…th its own batchResponse

A single BatchResponse was shared by every batchRequest of the SOAP
body: the elements of all batch requests were merged into one reply and
the requestID was overwritten on each iteration. Marshal one
batchResponse per batchRequest into the SOAP body, keep the upfront
instance for the errors detected before the body is walked, and answer
a batchRequest which fails schema validation under its own requestID.
The DSMLv2 schema is now on the test classpath: without it the
unmarshaller silently skips validation.